1. Field of the Invention
The present invention relates to transport of Internet Protocol (IP) packets via a multi-homed transport such as Stream Control Transmission Protocol (SCTP). More particularly, the present invention relates to source address selection for multi-homed transport of packets between multi-homed peers.
2. Description of the Related Art
The worldwide deployment of Internet Protocol (IP) networks has resulted in the development of newer protocols that extend the capabilities of IP networks. For example, telecommunications services providers providing telephony and wireless PCS services have begun deploying IP-based telecommunications for transport of signaling messages (e.g., Signaling System 7 (SS7) protocol messages) as well as trunk (i.e., bearer channel) messages.
The Internet Engineering Task Force (IETF) Network Working Group has published a proposal for extending IP networks, considered connectionless networks, to support a reliable transport protocol, namely the Request for Comments (RFC) 2960 by Stewart et al., “Stream Control Transmission Protocol”, October 2000, available on the World Wide Web at the address http://www.ietf.org/rfc/rfc2960.txt, the disclosure of which is incorporated in its entirety herein by reference. RFC 2960 is an example of a multi-homed transport protocol, where an SCTP endpoint can be considered multi-homed if there exists more than one transport address that can be used as a destination address to reach that SCTP endpoint.
SCTP protocol is similar to Transmission Control Protocol (TCP) as specified in RFC 793, in that SCTP provides security and flow control. One difference between SCTP and TCP is that SCTP is connection-oriented in nature (i.e., point-to-point), whereas TCP is byte-oriented in nature, where a sequence of bytes supplied at one endpoint are received at the destination endpoint in the same endpoint (i.e., without any reordering). SCTP, however, is not byte-oriented but rather is chunk-oriented: a “chunk” is a container for transporting data such as an SS7 signaling unit. The use of a “chunk” oriented protocol as opposed to byte-oriented TCP protocol provides flexibility in the “granularity” of data flows and acknowledgements.
In addition, TCP defines an endpoint based on a single IP address and a corresponding single port number; hence, if a TCP connection relies on an IP address that encounters a failure on the network, the TCP connection is broken, requiring opening a new TCP connection using a different IP address or a different physical interface.
In contrast, SCTP defines an endpoint as having one unique port number and one or more IP addresses. Hence, SCTP provides “multi-homing”, where multiple IP addresses are available for the same SCTP connection, also referred to as an “association”. The association exists between two SCTP endpoints, where each endpoint has a unique port number and one or more available IP addresses. Hence, if an SCTP endpoint has an Ethernet interface that has a corresponding IP address and that encounters a failure, the SCTP protocol enables the SCTP endpoint to switch to a different IP address and begin transmission on the corresponding Ethernet interface, while maintaining the flow of packets.
FIG. 1 is a block diagram illustrating multi-homed endpoints 10 communicating via an IP network 12 using a multi-homed transport protocol, such as SCTP. Each endpoint 10a and 10b includes at least two interfaces 14: the endpoint 10a includes a primary interface 14a having IP address “1” and a secondary interface 14b having IP address “2”, and the endpoint 10b includes a primary interface 14c having IP address “3” and a secondary interface 14d having IP address “4”. As described above, each endpoint 10a and 10b is identified by one port number and two IP addresses, such that two IP addresses exist on each endpoint 10: as illustrated in FIG. 1, the endpoint 10a is identified by “Port 0” and its interfaces 14a and 14b are identified by respective IP addresses “1” and “2”; the endpoint 10b is identified by “Port 1” and its interfaces 14c and 14d are identified by respective IP addresses “3” and “4”.
The RFC 2960 specifies that each endpoint 10a and 10b is able to provide the other endpoint (10b and 10a) during association startup with a list of transport addresses (each specifying SCTP port and IP addresses) through which the corresponding endpoint can be reached and from which it will originate SCTP packets. The existence of two IP addresses for each SCTP endpoint 10 results in four (4) possible source address/destination address pairs that can be used to send packets between the endpoints: 1-to-3, 1-to-4, 2-to-3, and 2-to-4. Hence, upper-layer messaging protocol layers (e.g, an SS7 application) executed by the endpoint 10a send a message to the SCTP port (Port 0), enabling the message to be output via either of the interfaces 14a or 14b. 
The RFC 2960 does not specify the manner in which an IP address (e.g., “1” or “2”) should be selected for a corresponding interface (e.g., 14a or 14b), but rather relies on underlying routing protocols for source address selection. Alternatively, multi-homed transport mechanisms may use static routing which does not provide any feedback about changes within the network path.
Hence, arbitrary implementations for source address selection may create numerous problems. For example, the source address selection may not be accurate due to stale information caused by the reconvergence times of the underlying routing protocol. In some instances, the source address selected by the routing protocol may not be an address utilized by the multi-homed transport. If static routing is used, source address selection is limited to the routing information that was statically provisioned: in most cases a sender lacks any information for selecting a source address, except possibly a measured round-trip-time (RTT) that is maintained on a per-destination basis.